Advanced multi-factor authentication

ABSTRACT

Advanced multi-factor authentication is disclosed. Data describing a change in a spatial position of a computing device from a first point in time to a second point in time may be captured. Data describing a change in a spatial position of an object within a field of view of the computing device from the first point in time to the second point in time may further be captured. Access to at least one resource may be authorized when the data describing the change in the spatial position of the object within the field of view of the computing device from the first point in time to the second point in time is expected based at least in part on the data describing the change in the spatial position of the computing device from the first point in time to the second point in time.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 14/462,992,filed on Aug. 19, 2014, entitled “Authentication Via Accelerometer,” theentire disclosure of which is hereby incorporated herein by reference inits entirety.

BACKGROUND

Advanced multi-factor authentication may be provided. Mobile devices areroutinely equipped with numerous sensors, including accelerometers. Anaccelerometer is an electromechanical device that will measureacceleration forces. These forces may be static, like the constant forceof gravity, and/or they could be dynamic, such as those caused by movingor vibrating the accelerometer. By measuring the amount of staticacceleration due to gravity, the angle at which the device is tilted maybe measured. By sensing the amount of dynamic acceleration, thedirection and speed that the device is moving may be detected.Conventional devices, however, do not make use of the accelerometer toprovide device security. Instead, most devices rely on a static passcodeor pattern unlock. Even the most advanced consumer devices rely onfacial identification at most.

BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the present disclosure can be better understood withreference to the following diagrams. The drawings are not necessarily toscale. Instead, emphasis is placed upon clearly illustrating certainfeatures of the disclosure. Moreover, in the drawings, like referencenumerals designate corresponding parts throughout the several views. Inthe drawings:

FIG. 1 is a block diagram of an operating environment for providingdevice management.

FIG. 2 is a flow chart illustrating a method for providing anaccelerometer-based authentication scheme;

FIG. 3 illustrates a use case for authentication using an accelerometer;

DETAILED DESCRIPTION

The following detailed description refers to the accompanying drawings.Wherever possible, the same reference numbers are used in the drawingsand the following description to refer to the same or similar elements.While embodiments of the disclosure may be described, modifications,adaptations, and other implementations are possible. For example,substitutions, additions, or modifications may be made to the elementsillustrated in the drawings, and the methods described herein may bemodified by substituting, reordering, or adding stages to the disclosedmethods. Accordingly, the following detailed description does not limitthe disclosure. Instead, the proper scope of the disclosure is definedby the appended claims.

Advanced multi-factor authentication may be provided. Mobile devicesfrequently have a configurable setting to lock the device upon somecondition, such as pressing a button or expiration of a time period ofinactivity. In the locked state, access to many functions of the devicemay be limited. For example, a lock screen may be displayed with thetime, date, and some message notifications, but attempts to open theapplications associated with those notifications may be denied until auser is authorized. In some cases, passcodes, finger-swipe patterns, andbiometric data (e.g., facial recognition, fingerprints, etc.) may beused as authorization.

Consistent with embodiments of this specification, a deviceaccelerometer may be used to replace and/or supplement userauthentication methods. As described herein, an accelerometer maycomprise and/or include a gyroscope, a motion capture camera, agradiometer, and/or other electromechanical components capable ofdetecting a device's orientation, velocity, directional movement, shock,vibration, coordinate acceleration, and/or other changes in spatialposition. In some embodiments, an accelerometer behaves as a damped masson a spring. When the accelerometer experiences an acceleration, themass is displaced to the point that the spring is able to accelerate themass at the same rate as the casing. The displacement is then measuredto give the acceleration, often using piezoelectric, piezoresistive andcapacitive components to convert the mechanical motion into anelectrical signal.

User devices, such as cellular phones, tablets, laptops, may includeaccelerometers as part of their internal components. In someembodiments, an external device may be used to provide the accelerometer(e.g., a video game controller) that may provide the accelerationmeasurements to another device. Users of such devices may establish anauthorization movement of the accelerometer-enabled device that may beused to permit those users access to at least some of the functionalityof the device. For example, a user may establish a clockwise turn whileraising the device as their particular authorization movement.

In some embodiments, the movement may be coupled with a secondaryauthorization technique, such as facial recognition, to increasesecurity and/or prevent accidental unlocking of the device. For example,the clockwise+raise movement may need to be performed while a camera onthe device is aimed at the user's face. The movements tracked by theaccelerometer should correlate with the movement of the camera's fieldof view and a recognition of the user associated with the movement inorder to comprise a successful authorization. In one embodiment,performing a facial recognition on the user of the device can includecorrelating a video capture by the device to an inverse of theauthentication movement. Successful authorization may allow the user toperform functions on the device and/or access content, resources, orphysical locations.

Compliance with management and/or security policies may be required byan enterprise before allowing access to content, or to preventremediation actions from being taken. For example, a management policymay require that a device have a passcode set, that a specificapplication be used for real-time communications, and that only userswithin the same user group may be messaged during working hours.Security policies may restrict encryption of the message traffic to anencryption key assigned by the enterprise, so that messages may belogged and/or audited, and may prohibit the sending of files or images.Failure to comply with these policies may result, for example, inrestricting an input from being transmitted at all, overriding a userpreference associated with the application (e.g., using the enterpriseencryption key instead of a personal key), and/or preventing theestablishment of a communication session between users.

The security policies may further comprise requirements to protect thecontent of the communication from unauthorized users. For example, anotification message on the receiving user's device may be prohibitedfrom displaying any and/or all of the contents of the communicationuntil an authorization, such as a passcode or encryption key password,has been entered. In some embodiments, the message may be displayed, butthe contents may be obfuscated, such as by blurring or covering textwith black boxes. Other restrictions may prevent any and/or all devicesparticipating in the communication from capturing the contents of themessage, such as by preventing logging and/or disabling screen capturecapabilities. A further refinement may vary a refresh rate associatedwith different portions of a display of the contents such that attemptsto photograph the screen may be blocked or at least allowed to captureonly portions of those contents.

The technical effects of some embodiments of this disclosure may includeestablishing control of access to networks and resources for userdevices when access lists may not be predefined, and reducing and/oreliminating the burden of predefining access lists to control access tonetworks and resources. Moreover, the technical effects of someembodiments may include enhancing network access control by assigningspecific access rights based on access lists to client devicesauthorized to access associated network beacons and resources.

Other technical effects of some embodiments of this disclosure may offergroup management solutions to managing content access and distribution.For example, users of a sales group may have read access to marketingdocuments and presentations, while users in a marketing group may beable to edit and/or annotate the market documents. Similarly, users inan accounting or business services group may be the only ones withaccess to enterprise financial documents. These access controls may beprovided by distributing authorization credentials to devices associatedwith users of the respective group. Each user may then authenticate totheir device, such as by inputting a username, password, authenticationkey, and/or biometric data, before the device may access and/or retrievethe content authorized for distribution to that device. Theseauthentication types are provided as examples only and are not intendedto be limiting as many other types of user authentication are in useand/or may be contemplated in the future.

Content access may be further limited by policies that enforce othercompliance restrictions based on properties of the device such as time,location, device security and/or integrity, presence of another device,software versions, required software, etc. For example, educationalsettings may designate student and instructor groups. These groups maybe further assigned to specific classes such that only student groupmembers associated with a given class may access content associated withthat class. Further, edit access to the content for the class may berestricted to the user(s) in the instructor group and/or student groupmembers may be permitted to add content that only the instructor mayview (e.g., homework assignments). In some embodiments, the instructorgroup user(s) may be able to push content to student group user(s)and/or activate temporary control of the students' devices to preventthe devices from accessing non-class related content during class time.

To reduce the cost of ownership of user devices and cellular and/or dataservice charges associated with use of such user devices, an enterprisesuch as an educational institution and/or a business may implement a“bring your own device” (BYOD) policy to allow an employee to usehis/her personal device to access enterprise resources rather thanprovide the user with an enterprise owned user device for such purpose.To support such a BYOD policy, a user device administrator (e.g., an ITadministrator) may manage a group of personally owned user devices,using a management application executed by a management server incommunication with the user devices over a network, to provide the userdevices with secure access to enterprise resources.

The user device administrator may enroll user devices into themanagement system to monitor the user devices for securityvulnerabilities and to configure the user devices for secure access toenterprise resources. The user device administrator may create and/orconfigure at least one configuration profile using a user interfaceprovided by the management system. A configuration profile may comprisea set of instructions and/or settings that configure the operationsand/or functions of a user device, which may ensure the security of theaccessed resources. The user device administrator may, for instance,configure an enterprise email configuration profile by specifying thenetwork address and access credentials of an enterprise email accountthat the users of the user devices are authorized to access. Otherconfiguration policies may include, but are not limited to, hardware,software, application, function, cellular, text message, and data userestrictions, which may be based at least in part on the current timeand/or location of the restricted user device. The user deviceadministrator may thereafter deploy the configuration profiles tospecific user devices, such as to groups of user devices of users withsimilar roles, privileges and/or titles.

Access credentials may uniquely identify a client device and/or the userof the client device. For example, the access credentials for a user maycomprise a username, a password, and/or biometric data related to facialrecognition, retina recognition, fingerprint recognition, and the like.Access credentials related to a device may uniquely identify the deviceand may comprise, for example, a unique hardware identifier such as aGUID (Globally Unique Identifier), UUID (Universally Unique Identifier),UDID (Unique Device Identifier), serial number, IMEI (InternationallyMobile Equipment Identity), Wi-Fi MAC (Media Access Control) address,Bluetooth MAC address, a CPU ID, and/or the like, or any combination oftwo or more such hardware identifiers. Additionally, the accesscredentials may be represented by a unique software identifier such atoken or certificate, based at least in part on the aforementionedunique hardware identifiers.

The user devices may also have access to personal configuration profilesthat may be created by the users of the user devices. The user devicesmay, for instance, have access to a personal email configuration profilethat was created by a user of the user device to provide access to herpersonal email account. Thus, a user device enrolled in a BYODmanagement system may have more than one configuration profile for agiven use of the user device, such as a personal email configurationprofile and an enterprise email configuration profile that are both usedfor accessing email accounts on the user device.

The user devices may be instructed to enable and/or disable certainconfiguration profiles according to authorization rights specified bythe user device administrator, such as location and/or time-basedauthorization rights. For example, a BYOD policy may specify that userdevices enrolled in the BYOD management system are authorized forpersonal use outside of the workday and are authorized for business useduring the workday. Similarly, a BYOD device may be restricted toenterprise uses while in work locations and/or prohibited from accessingenterprise resources while outside of secure work locations. Toimplement such a policy, a user device administrator may instruct theuser devices to toggle between personal configuration policies andenterprise configuration policies based on factors such as the currenttime and/or location associated with the user device.

The current time may be based on the current time at the currentlocation of the user device, which may be determined by GPS, Wi-Fi,Cellular Triangulation, etc., or may be based on the current time at aconfigured primary location associated with the user device, which maybe the primary office location of an employee user of the user device.As an example, time-based configuration profile toggling may be providedby instructing a user device to enable business configuration profilesand disable personal configuration profiles while the current time isbetween 9 AM and 5 PM at the current location of the user device, and todisable business configuration profiles and enable personalconfiguration profiles while the current time is between 5 PM and 9 AMat the current location of the user device.

FIG. 1 illustrates a networked environment 100 according to variousembodiments. The networked environment 100 includes a network 110, aclient device 120, an authentication server 130, and a compliance server140. The network 110 comprises, for example any type of wireless networksuch as a wireless local area network (WLAN), a wireless wide areanetwork (WWAN), and/or any other type of wireless network now knownand/or later developed. Additionally, the network 110 may comprise theInternet, intranets, extranets, microwave networks, satellitecommunications, cellular systems, PCS, infrared communications, globalarea networks, and/or other suitable networks, etc., and/or anycombination of two or more such networks. It should be understood thatembodiments described herein may be used to advantage in any type orcombination of wired and/or wireless networks.

In some embodiments, the network 110 facilitates the transport of databetween at least one client device, such as client device 120, theauthentication server 130, and the compliance server 140. Client devicesmay include a laptop computer, a personal digital assistant, a cellulartelephone, a set-top device, music players, web pads, tablet computersystems, game consoles, and/or other devices with like capability.Client device 120 comprises a wireless network connectivity component,for example, a PCI (Peripheral Component Interconnect) card, USB(Universal Serial Bus), PCMCIA (Personal Computer Memory CardInternational Association) card, SDIO (Secure Digital Input-Output)card, NewCard, Cardbus, a modem, a wireless radio transceiver (includingan RFID transceiver), near-field communications (NFC) transceiver,and/or the like. Additionally, the client device 120 may include aprocessor for executing applications and/or services, and a memoryaccessible by the processor to store data and other information. Theclient device 120 is operable to communicate wirelessly with theauthentication server 130 and the compliance server 140 with the aid ofthe wireless network connectivity component.

Additionally, the client device 120 may store in memory an agent app(i.e., application) 122, a device profile 124, user access credentials126, and potentially other data and/or applications. In someembodiments, the device profile 124 may include a software identifier, ahardware identifier, and/or a combination of software and hardwareidentifiers. For instance, the device identifier may be a uniquehardware identifier such as a MAC address, a CPU ID, and/or otherhardware identifiers. The user access credentials 126 may include ausername, a password, and/or biometric data related to facialrecognition, retina recognition, fingerprint recognition, and the like.Additionally, the device profile 124 may include a listing of hardwareand software attributes that describe the client device 120. Forinstance, the device profile 124 may include hardware specifications ofthe client device 120, version information of various software installedon the client device 120, and/or any other hardware/software attributes.Additionally, the device profile 124 may also include data indicating adate of last virus scan, a date of last access by IT, a date of lasttune-up by IT, and/or any other data indicating a date of last devicecheck.

The client device 120 may further be configured to execute variousapplications such as the agent application 122. The agent application122 may be executed to exchange information with other servers and/ordevices through network 110. In some embodiments, agent application 122may collect information about the status of client device 120 as well asreceive and/or enforce compliance rules 142 from compliance server 140.

The client device 120 may also be configured to execute otherapplications such as, for example, browser applications, emailapplications, physical access applications, word processingapplications, spreadsheet applications, database applications, and/orother applications. For instance, a browser and/or word processingapplication may be executed in the client device 120, for example, toaccess and render network pages, such as web pages, documents, and/orother network content served up by authentication server 130, thecompliance server 140, and/or any other computing system.

The authentication server 130 and the compliance server 140 can each beimplemented as, for example, a server computer and/or any other systemcapable of providing computing capability. Further, the authenticationserver 130, compliance server 140, and any other system described hereinmay be configured with logic for performing the methods described inthis disclosure. Although one authentication server 130 and onecompliance server 140 are depicted in FIG. 1, certain embodiments of thenetworked environment 100 include more than one authentication server130 and/or compliance server 140. At least one of the servers may beemployed and arranged, for example, in at least one server bank,computer bank, and/or other arrangements. For example, the servercomputers together may include a cloud computing resource, a gridcomputing resource, and/or any other distributed computing arrangement.Such server computers may be located in a single installation and/or maybe distributed among many different geographical locations. For purposesof convenience, the authentication server 130 and the compliance server140 are each referred to herein in the singular.

Various applications and/or other functionality may be executed in theauthentication server 130 and the compliance server 140, respectively,according to certain embodiments. Also, various data is stored in a datastore that is part of and/or otherwise accessible to the authenticationserver 130 and/or that is part of and/or otherwise accessible to thecompliance server 140. The data stored in each of the data stores may beaccessed, modified, removed, and/or otherwise manipulated in associationwith the operation of the applications and/or functional entitiesdescribed herein.

The components executed in the authentication server 130 may include anauthentication service 132, and may include other applications,services, processes, systems, engines, and/or functionality notdiscussed in detail herein. As used herein, the term “authenticationservice” is meant to generally refer to computer-executable instructionsfor performing the functionality described herein for authorizing andauthenticating client device 120. The authentication service 132 isexecuted to receive a request for access to resources 132 from anapplication executed on client device 120 and to determine whether togrant or deny the request. Upon determining to grant the request 132,the authentication service 132 may then send access credentials.

The data stored in the data store of the authentication server 130 mayinclude, for example, approved device identifiers, approved user accesscredentials, physical access credentials, resource access credentials,and potentially other data. The approved device identifiers represent alisting of device identifiers that have been pre-approved for potentialaccessing physical access credentials which may entitle holders ofclient devices 120 to access to various resources 132. The approveddevice identifiers may have been previously provided to theauthentication server 130 by a system administrator and/or the like. Theapproved user access credentials represent a listing of user accesscredentials 126 that have been pre-approved for accessing resources 132.

The components executed in the compliance server 140 include acompliance service 144, and may include other applications, services,processes, systems, engines, and/or functionality not discussed indetail herein. As used herein, the term “compliance service” is meant togenerally refer to computer-executable instructions for performing thefunctionality described herein for authorizing the devicecharacteristics of another device, such as client device 120. Thecompliance service 144 is executed to determine whether the devicecharacteristics of the client device 120 comply with the compliancerules 142 that are stored in the data store. For instance, thecompliance service 144 may identify the device characteristics from thedevice profile 124 of each client device 120. Additionally, thecompliance rules 142 represent a listing of management and securitypolicies, hardware restrictions, software restrictions, and/or mobiledevice management restrictions that may need to be satisfied by theclient device 120 prior to granting the request for access to resources132.

In some embodiments, hardware restrictions included in the compliancerules 142 may comprise restrictions regarding use of specific clientdevices 120 and specific client device features, such as, for instance,cameras, Bluetooth, IRDA, tethering, external storage, a mobile accesspoint, and/or other hardware restrictions. Software restrictionsincluded in the compliance rules 142 may comprise restrictions regardingthe use of specific client device operating systems and/or otherapplications, internet browser restrictions, screen capturefunctionality, and/or other software restrictions. Mobile devicemanagement restrictions included in the compliance rules 142 compriseencryption requirements, firmware versions, remote lock and wipefunctionalities, logging and reporting features, GPS tracking, and/orother mobile device management features.

The compliance service 144 may determine whether the devicecharacteristics of a client device 120 satisfy at least one of therestrictions enumerated in the compliance rules 142. For example, thecompliance service 144 may determine that a client device 120 that has acamera, Bluetooth capability, and is executing a specified version of anoperating system is compliant with the compliance rules 142. As anotherexample, the compliance service 144 may determine that a client device120 that is associated with an external storage unit and has screencapture functionality enabled is not compliant with the compliance rules142. All of these restrictions discussed above may affect whether theclient device 120 is entitled to use particular resources 132. In someembodiments, however, the compliance service 144 may not be used andphysical access authorization may be determined solely based on approveduser access credentials and/or approved device identifiers.

A user operating a client device 120 may wish to receive resources 132so that the user may physically access a building, location, door, gate,drawer, filing cabinet, storage unit, cabinet, etc. In some embodiments,the user may interact with an input device to manipulate a network pagedisplayed by a locally executed application, such as a browserapplication, to generate the request for access to a resource 132. Insome embodiments, the user may manipulate a user interface generated bya locally executed application to generate the request. In either case,the user may provide login information and/or the application mayautomatically retrieve the login information from the memory of theclient device 120. Login information may be, for instance, a unique username, a password, biometric data, and/or other types of user accesscredentials 126. The application may then communicate the request to theenterprise access application, which may generate and transmit therequest to the authentication service 132. In some embodiments, theenterprise access application may itself receive the input from the userdirectly and then transmit the access request to the authenticationserver 130.

Upon receiving the request, the authentication service 132 determineswhether to grant or deny the request. In some embodiments, theauthentication service 132 may first authenticate the client device 120and the user operating the client device 120. To this end, theauthentication service 132 determines whether the device identifierassociated with the client device 120 matches one of the identifierslisted in the listing of approved identifiers. For instance, the deviceidentifier of the client device 120 may be included as part of therequest transmitted by the enterprise access application. In someembodiments, the authentication service 132 may request the deviceidentifier from the client device 120 in response to receiving theaccess request. Upon identifying and/or receiving the device identifier,the authentication service 132 determines whether the device identifiermatches one of the approved identifiers stored in the data store. Insome embodiments, the authentication service 132 may authenticate theclient device 120 dynamically by determining whether the deviceidentifier is within a predetermined range of approved deviceidentifiers. In some embodiments, the authentication service 132 mayauthenticate the client device 120 dynamically by performing analgorithm on the device identifier.

Additionally, the authentication service 132 may also authenticate theuser operating the client device 120 by determining whether the useraccess credentials 126 associated with the user match one of thecredentials in the listing of approved user access credentials. Forinstance, the user access credentials 126 associated with the user onthe client device 120 may be included as part of the access request 132transmitted by the enterprise access application 124. In someembodiments, the authentication service 132 may request the user accesscredentials 126 from the client device 120 in response to receiving theaccess request. Upon identifying and/or requesting the user accesscredentials 126, the authentication service 132 may determine whetherthe user access credentials 126 match one of the approved user accesscredentials stored in the data store. In some embodiments, theauthentication service 132 may authenticate the user operating theclient device 120 without also authenticating the client device 120. Inother words, certain authenticated users may be authorized to gain therequested access regardless of what device they used to submit theresource request.

In some embodiments, having authenticated the client device 120 and theuser operating the client device 120 as authorized to receive theresources 132, the authentication service 132 communicates with thecompliance service 144 to further authorize the client device 120 toreceive the resources 132. In some embodiments, the compliance service144 authorizes the client device 120 by determining whether devicecharacteristics of the client device 120 comply with applicablecompliance rules 142. For instance, the compliance service 144 mayidentify the device characteristics of the client device 120 from thedevice profile 124. All or part of the device profile 124 may have beenprovided by the client device 120 in conjunction with the request and/ormay be subsequently requested from the client device 120 by theauthentication service 132 and/or the compliance service 144. Thecompliance service 144 then analyzes the device characteristics todetermine whether the software restrictions, hardware restrictions,and/or device management restrictions defined in the compliance rules142 are satisfied and returns the result of the determination to theauthentication service 132. In an alternative embodiment, theauthentication service 132 may include and perform functionality fordetermining whether the client device 120 complies with the compliancerules 142.

If the authentication service 132 determines and/or receives adetermination that the client device 120 is authorized, theauthentication service 132 then associates the client device 120 withthe resources 132. In some embodiments, the authentication service 132sends the physical access credentials to the client device 120 andauthorizes the client device 120 to use such credentials in connectionwith accessing physical access points. In some embodiments, theauthentication service 132 may also send the physical access credentialsto physical access point.

In some embodiments, the resources 132 may be revoked at any time by theauthentication server 130. Revocation may occur for any number ofreasons, including but not limited to, a change in device profile 124, achange in approved device identifiers, a change in approved user accesscredentials, expiration of a defined time period, and/or a request fromthe user of the client device 120.

FIG. 2 is a flow chart setting forth the general stages involved in amethod 200 consistent with embodiments of this disclosure for providingan accelerometer-based authentication scheme. Method 200 may beimplemented using elements of networked environment 100 as describedabove, an example use case deployment 300, a schematic block diagram 400and a virtual desktop infrastructure (VDI) system 500, as describedbelow. Method 200 is described below with respect to operationsperformed by a computing device, with the understanding that such acomputing device may comprise any number devices programmed foroperation of any and/or all of the steps of method 200. The describedcomputing device may comprise, for example, client device 120,authentication server 130, and/or compliance server 140. Ways toimplement the stages of method 200 will be described in greater detailbelow.

Method 200 may begin at stage 205 where a computing device may receive arequest to unlock. For example, a user may perform an action on clientdevice 120, such as a swipe or button press, to indicate a desire tounlock the client device 120. In some embodiments, the request to unlockmay comprise a request to grant access to resources 132, such as files,apps, content, hardware functions, networks, etc. For example, therequest to unlock may comprise a request to activate a camera associatedwith client device 120.

Method 200 may then advance to stage 210 where the computing device maydetect an authorization movement. For example, client device 120 maycapture a movement and/or series of movements using an accelerometer. Insome embodiments, the accelerometer may comprise a component of clientdevice 120 and/or the accelerometer may comprise a component of asecondary device. For example, the accelerometer may comprise acomponent in a video game controller and/or other handheld device.

Method 200 may then advance to stage 215 where the computing device maycapture at least one secondary criterion. For example, client device 120may activate a camera and take a picture and/or video of the userperforming the authentication movement. In some embodiments, thesecondary criteria may be correlated with the movement, such as bycomparing the movement of the visual field seen by the camera with themovement detected by the accelerometer. Other secondary criterion maycomprise entry of a password, passcode, pattern, or security phraseand/or biometric data such as fingerprint, voice, and/or iris scanning.

Method 200 may then advance to stage 220 where the computing device maydetermine whether the user should be authenticated. For example, clientdevice 120 may determine whether the movement detected by theaccelerometer matches a pre-defined movement pattern associated with theuser.

In some embodiments, a certain amount of variability may be permitted.For example, the movement pattern may be recorded by a user raising thedevice eighteen inches and then rotating the device 270 degrees. Whenthe user later performs the authentication movement to unlock thedevice, they may only raise the device sixteen inches and/or may rotatethe device three hundred degrees. A configurable setting may allow forsome percentage of differential from the recorded movement—a largerdifferential percentage may comprise a less strict security policy,while a smaller differential percentage may comprise a stricter securitypolicy.

In some embodiments, the secondary criteria may be examined forcorrelation with the authentication movement. For example, a facialrecognition of the user may be performed using a camera of client device120 and/or an external camera. Some facial recognition algorithmsidentify facial features by extracting landmarks, or features, from animage of the subject's face. Other algorithms may use the motion of thecamera as a three-dimensional sensor to capture information about theshape of a face. This information is then used to identify distinctivefeatures on the surface of a face, such as the contour of the eyesockets, nose, and chin. Correlation of the movement may also beprovided by a secondary motion capture device that may independentlyverify that the user performing the motion is the same as the userholding the device. For example, a camera device (e.g., a Microsoft®Kinect motion capture device) may compare the face and movements of auser to the face and movements captured by the device itself.

In some embodiments, the authentication may be time and/or locationdependent. For example, client device 120 may require a differentauthentication movement during working hours or at a public location. Insome embodiments, the authentication movement may comprise a directionalfactor as a secondary criterion, such as requiring part of the movementto be in a northward direction, which may be detected by a compasscomponent of client device 120.

If the user is determined not to be authenticated at stage 220, method200 may advance to stage 230 where the computing device may captureinformation about the attempt to unlock. For example, client device 120may take a picture of an unauthorized user attempting to unlock thedevice and/or may capture other biometric and/or environmentalinformation. Otherwise, method 200 may advance to stage 235 where thecomputing device may unlock and/or grant access to the requestedresources 132.

FIG. 3 illustrates an example use case 300 for providing deviceauthentication using an accelerometer. In use case 300, a user 310 mayinteract with a user device 320 and/or a motion capture device 330. Insome embodiments, user device 320 may comprise an embodiment of clientdevice 120. User device 320 may comprise components such as anaccelerometer 340 and a camera 360. Motion capture device 330 maycomprise similar components.

In use case 300, user 310 may manipulate user device 320 by a firstmotion 380(A), such as raising user device 320, and a second motion380(B), such as rotating user device 320 clockwise. These motions may betracked and/or recorded by accelerometer 340. In some embodiments, theactions of user 310 may be tracked by camera 360 and/or motion capturedevice 330. The first motion 380(A) and second motion 380(B) may becompared to a recorded authentication movement associated with user 310to determine if a request to unlock the device should be granted, asdescribed above with respect to method 200.

The authentication movements may utilize increasing degrees ofcomplexity to make attempts to impersonate the authorized user moredifficult. A first degree of complexity may comprise a tilting movementbased on tilting the four corners of user device 320. User 310 may setany combination of upper and lower right with upper and lower leftcorners up to N number of movements. For each N there are(N*(N−1)*N*(N−1)) combinations, which reflects all combinations withoutsequential duplicates. A user interface on user device 320 may displayan indicator such as a marble that rolls to each corner as that corneris tilted down.

A second degree of complexity may comprise a movement across a flatsurface, such as a table top. The accelerometer 340 may track movementsof user device 320 in the X and Y-axis, but allows for near-infinitecombinations. Some examples of movements may comprise a figure-8, ageometric shape (e.g., triangle, square, circle), a handwrittencharacter, a smiley face drawing, and/or the outline of a table or desk.

A third degree of complexity, harder to impersonate than the first andsecond degrees, may comprise a movement through free space. Somepossible combinations comprise a sequence of movements such as forward,up left, down, and then right, shaking user device 320, moving userdevice 320 as if conducting a symphony, user 310 moving their armsthrough a stretching or yoga exercise, and/or tracing a shape in theair. Each of the degrees of complexity may be increased by requiringadditional movement components such as orienting the user device 320 ina particular compass direction.

The flowchart of FIG. 2 and use case of FIG. 3 show examples of thefunctionality and operation of implementations of components describedherein. The components described herein can be embodied in hardware,software, or a combination of hardware and software. If embodied insoftware, each element can represent a module of code or a portion ofcode that includes program instructions to implement the specifiedlogical function(s). The program instructions can be embodied in theform of source code that includes human-readable statements written in aprogramming language or machine code that includes machine instructionsrecognizable by a suitable execution system, such as a processor in acomputer system or other system. If embodied in hardware, each elementcan represent a circuit or a number of interconnected circuits thatimplement the specified logical function(s).

Although the flowchart of FIG. 2 and use case of FIG. 3 may show aspecific order of execution, it is understood that the order ofexecution can differ from that which is shown. The order of execution oftwo or more elements can be switched relative to the order shown. Also,two or more elements shown in succession can be executed concurrently orwith partial concurrence. Further, in some examples, one or more of theelements shown in the flowcharts can be skipped or omitted. In addition,any number of counters, state variables, warning semaphores, or messagesmight be added to the logical flow described herein, for purposes ofenhanced utility, accounting, performance measurement, ortroubleshooting aid. It is understood that all such variations arewithin the scope of the present disclosure.

The client device 120, authentication server 130, compliance server 140,or other components described herein can each include at least oneprocessing circuit. Such a processing circuit can include one or moreprocessors and one or more storage devices that are coupled to a localinterface. The local interface can include a data bus with anaccompanying address/control bus or any other suitable bus structure.

The one or more storage devices for a processing circuit can store dataor components that are executable by the one or processors of theprocessing circuit. The agent application 122, authentication service132, compliance service 144, or other components can be stored in one ormore storage devices and be executable by one or more processors. Also,a data store, such as the data store 113 or the client data store 143,can be stored in the one or more storage devices.

The agent application 122, authentication service 132, complianceservice 144, and other components described herein can be embodied inthe form of hardware, as software components that are executable byhardware, or as a combination of software and hardware. If embodied ashardware, the components described herein can be implemented as acircuit or state machine that employs any suitable hardware technology.Such hardware technology can include one or more microprocessors,discrete logic circuits having logic gates for implementing variouslogic functions upon an application of one or more data signals,application specific integrated circuits (ASICs) having appropriatelogic gates, programmable logic devices (e.g., field-programmable gatearray (FPGAs), and complex programmable logic devices (CPLDs)).

Also, one or more or more of the components described herein thatincludes software or program instructions can be embodied in anynon-transitory computer-readable medium for use by or in connection withan instruction execution system such as a processor in a computer systemor other system. The computer-readable medium can contain, store, ormaintain the software or program instructions for use by or inconnection with the instruction execution system.

The computer-readable medium can include physical media, such as,magnetic, optical, semiconductor, or other suitable media. Examples of asuitable computer-readable media include, but are not limited to,solid-state drives, magnetic drives, flash memory. Further, any logic orcomponent described herein can be implemented and structured in avariety of ways. One or more components described can be implemented asmodules or components of a single application. Further, one or morecomponents described herein can be executed in one computing device orby using multiple computing devices.

It is emphasized that the above-described examples of the presentdisclosure are merely examples of implementations to set forth for aclear understanding of the principles of the disclosure. Many variationsand modifications can be made to the above-described examples withoutdeparting substantially from the spirit and principles of thedisclosure. All such modifications and variations are intended to beincluded herein within the scope of this disclosure. In particular,while elements depicted in the FIGs. and described herein may bereferred to in a particular case (i.e., singular or plural; e.g.,resources 136), it is emphasized that such elements may be implementedin alternate cases (i.e., plural or singular, respectively; e.g., aresource 136) without departing from the spirit and principles of thedisclosure.

Therefore, the following is claimed:
 1. A non-transitorycomputer-readable medium embodying a program executable in a computingdevice, the program, when executed by the computing device, beingconfigured to cause the computing device to at least: capture datadescribing a change in a spatial position of the computing device from afirst point in time to a second point in time; capture data describing achange in a spatial position of an object within a field of view of thecomputing device from the first point in time to the second point intime; determine whether the data describing the change in the spatialposition of the object within the field of view of the computing devicefrom the first point in time to the second point in time is expectedbased at least in part on the data describing the change in the spatialposition of the computing device from the first point in time to thesecond point in time; and, when the data describing the change in thespatial position of the object within the field of view of the computingdevice from the first point in time to the second point in time isexpected based at least in part on the data describing the change in thespatial position of the computing device from the first point in time tothe second point in time, authorize at least one resource to beaccessed.
 2. The non-transitory computer-readable medium of claim 1,wherein the data describing the change in the spatial position of thecomputing device from the first point in time to the second point intime comprises data describing a distance that the computing devicemoved from the first point in time to the second point in time.
 3. Thenon-transitory computer-readable medium of claim 1, wherein the datadescribing the change in the spatial position of the computing devicefrom the first point in time to the second point in time comprises datadescribing a direction that the computing device moved from the firstpoint in time to the second point in time.
 4. The non-transitorycomputer-readable medium of claim 1, wherein the data describing thechange in the spatial position of the computing device from the firstpoint in time to the second point in time comprises data describing achange in an orientation of the computing device from the first point intime to the second point in time.
 5. The non-transitorycomputer-readable medium of claim 1, wherein the data describing thechange in the spatial position of the object within the field of view ofthe computing device from the first point in time to the second point intime comprises data describing a distance that the object within thefield of view of the computing device moved from the first point in timeto the second point in time.
 6. The non-transitory computer-readablemedium of claim 1, wherein the data describing the change in the spatialposition of the object within the field of view of the computing devicefrom the first point in time to the second point in time comprises datadescribing a direction that the object within the field of view of thecomputing device moved from the first point in time to the second pointin time.
 7. The non-transitory computer-readable medium of claim 1,wherein the data describing the change in the spatial position of theobject within the field of view of the computing device from the firstpoint in time to the second point in time comprises data describing achange in an orientation of the object within the field of view of thecomputing device from the first point in time to the second point intime.
 8. A system, comprising: at least one processor; and, at least onememory comprising executable instructions, which when executed by the atleast one processor, cause the processor to at least: capture datadescribing a change in a spatial position of a computing device from afirst point in time to a second point in time; capture data describing achange in a spatial position of an object within a field of view of thecomputing device from the first point in time to the second point intime; determine whether the data describing the change in the spatialposition of the object within the field of view of the computing devicefrom the first point in time to the second point in time is expectedbased at least in part on the data describing the change in the spatialposition of the computing device from the first point in time to thesecond point in time; and, when the data describing the change in thespatial position of the object within the field of view of the computingdevice from the first point in time to the second point in time isexpected based at least in part on the data describing the change in thespatial position of the computing device from the first point in time tothe second point in time, authorize at least one resource to beaccessed.
 9. The system of claim 8, wherein the at least one memoryfurther comprises executable instructions, which when executed by the atleast one processor, cause the at least one processor to: identify arequest to access the at least one resource.
 10. The system of claim 9,wherein the request comprises a request generated based at least in parton an action of a user of the computing device.
 11. The system of claim9, wherein the request comprises a request generated based at least inpart on an action of a user of a secondary computing device.
 12. Thesystem of claim 8, wherein authorizing the at least one resource to beaccessed comprises authorizing a user of the computing device to accessthe at least one resource using the computing device.
 13. The system ofclaim 8, wherein authorizing the at least one resource to be accessedcomprises authorizing a user of a secondary computing device to accessthe at least one resource using the secondary computing device.
 14. Amethod, comprising: capturing data describing a change in a spatialposition of a computing device from a first point in time to a secondpoint in time; capturing data describing a change in a spatial positionof an object within a field of view of the computing device from thefirst point in time to the second point in time; determining whether thedata describing the change in the spatial position of the object withinthe field of view of the computing device from the first point in timeto the second point in time is expected based at least in part on thedata describing the change in the spatial position of the computingdevice from the first point in time to the second point in time; and,when the data describing the change in the spatial position of theobject within the field of view of the computing device from the firstpoint in time to the second point in time is expected based at least inpart on the data describing the change in the spatial position of thecomputing device from the first point in time to the second point intime, authorizing at least one resource to be accessed.
 15. The methodof claim 14, wherein authorizing at least one resource to be accessedcomprises unlocking at least one function of at least one of: thecomputing device or a secondary computing device.
 16. The method ofclaim 14, further comprising: when the data describing the change in thespatial position of the object within the field of view of the computingdevice from the first point in time to the second point in time is notexpected based at least in part on the data describing the change in thespatial position of the computing device from the first point in time tothe second point in time, preventing the at least one resource frombeing accessed.
 17. The method of claim 14, wherein the object withinthe field of view of the computing device comprises a user of thecomputing device.
 18. The method of claim 17, further comprising:determining whether the data describing the change in the spatialposition of the computing device from the first point in time to thesecond point in time is expected based at least in part on a pre-definedauthentication movement associated with the user of the computingdevice; and, when the data describing the change in the spatial positionof the computing device from the first point in time to the second pointin time is expected based at least in part on the pre-definedauthentication movement associated with the user of the computingdevice, authorizing the user of the computing device to access the atleast one resource.
 19. The method of claim 14, wherein the objectwithin the field of view of the computing device comprises a user of asecondary computing device.
 20. The method of claim 19, furthercomprising: determining whether the data describing the change in thespatial position of the computing device from the first point in time tothe second point in time is expected based at least in part on apre-defined authentication movement associated with the user of thesecondary computing device; and, when the data describing the change inthe spatial position of the computing device from the first point intime to the second point in time is expected based at least in part onthe pre-defined authentication movement associated with the user of thesecondary computing device, authorizing the user of the secondarycomputing device to access the at least one resource.